<HTML>

<BODY BGCOLOR="white">

<center>
<FONT SIZE=+2 COLOR="#BB0000">CS346 - Spring 2011<BR>Database System Implementation</FONT>
</center>

<p>
<table border=0 cellpadding=4 cellspacing=10 width="100%">
<tr><td width="100%" bgcolor="#ccccff"><font face="Arial">
<center><b>Use of Memory in RedBase</b></center>
</font></td></tr>
</table>

One way to win the <a
href="project.html#contest">RedBase
I/O Efficiency Contest</a> without increasing the size of the PF
buffer pool is to allocate a separate chunk of memory that's used for
your own separately-managed large buffer pool (for pages, records,
whatever). Obviously doing so is not allowed as far as the contest is
concerned. For the contest, if you wish to store data from the
database in allocated memory you have two options:

<ol>

<li> You are permitted to allocate small amounts of memory, e.g., to
store a fixed amount of header information or a couple of records at
a time.

<p><li> If you want to allocate memory for full pages of records or
other data, e.g., to implement a nested-block or RID-based join, you
can use the "scratch pages" feature in the <a href="pf.html">PF
Component</a> (see the PF specification for details). Every time you
need a page worth of scratch memory, call
<tt>PF_Manager::AllocateBlock</tt>, which allocates a pinned page of
memory in the buffer pool and returns a pointer to it. When you are
done using the scratch memory, call <tt>PF_Manager::DisposeBlock</tt>
on this pointer to release the buffer page.

</ol>

<p>
You are welcome to implement data caching mechanisms that do not use
the buffer, either now or in your extension, but please disable such
mechanisms when you turn in your basic project if you want to enter
the contest.

<p>
Feel free to contact the instructor or TA if you have specific
questions about this policy as it relates to your own implementation.


</BODY>
